FIG. 1 shows the current type-length-value (TLV) representation of an IE 100 including a type field 105, a length field 110 and a value field 115, as specified by the IEEE 802.21 standard. Alternatively, the TLV fields may represent other fields such as a header, or MIH service data such as a command or an event.
The type field 105 indicates the type of the IE and has defined identification (ID) values in the IEEE 802.21 standard. The value field 115 contains the payload or the value of the IE 100. In a first scenario, if the number of octets occupied by the value field 115 is less than or equal to 127, the size of the length field 110 is always one (1) octet and the most significant bit (MSB) 120 of the octet is set to the value ‘0’. In a second scenario, if the number of octets occupied by the value field 115 is greater than 127, then the size of the length field 110 is at least “x” octets, where “x” is greater than or equal to two (2). In this case, the MSB 125 of the first octet of the length field 110 is set to the value ‘1’ and the remaining 7 bits of the first octet indicate the number of additional octets that are appended to the first octet. The number represented by the second octet of the length field 110 indicates the total size of the value field 115.
There is a problem with the length field explanation as specified in IEEE 802.21. Specifically, in the second scenario of the length field interpretation, the IEEE 802.21 standard specifies that the number represented by the second octet of the length field indicates the total size of the value field. This is inaccurate because the number represented by the second octet does not indicate the length of the value field. Instead, the number represented by the additional appended octets, starting from the second octet, indicates the length of the value field. In addition, the value of the additional octets should represent the length of the value field in octets as opposed to bits. Thus, the length field is not efficiently used.
FIG. 2 shows the current format of an MIHF frame 200 specified by the IEEE 802.21 standard. The IEEE 802.21 standard specifies that the MIHF frame 200 is composed of an MIHF fixed header 205 and an MIHF variable load 210. The MIHF variable load 210 is composed of an MIHF variable header 215 and an MIHF payload 220.
The IEEE 802.21 standard specifies that the MIHF fixed header 205 is mandatory. Table 1 below shows the contents of the MIHF fixed header 205 as specified in IEEE 802.21:
TABLE 1MIHF Fixed Header DescriptionSizeField Name(bits)DescriptionVersion4This field is used to specify the version ofprotocol used. The importance of this is seenin downwards compatibility handling in thefuture.ACK-Req1This field is used for requesting anacknowledgement for the message.ACK-Rsp1This field is used for responding to therequest for an acknowledgement for themessage.Reserved4This field is intentionally kept reserved. Inun-used case, it all the bits of this field areto be set to ‘0’.MIH Message ID16Combination of the following 3 fields.(MID)Service Identifier4Identifies the different MIH services,(SID)possible values are:1: System Management2: Event Service3: Command Service4: Information ServiceOperation Code3Type of operation to be performed with(Opcode)respect to the SID, possible values are:1: Request2: Response3: IndicationAction Identifier9This indicates the action to be taken with(AID)respect to the SID.Number of8Indicates the number of header identifiersAdditional(TLV for each) included in the variableHeaderMIHF header part.IdentifiersTransaction ID16This field is used for matching Request andResponse as well as matching Request,Response and Indication to an ACK.Variable Load16Indicates the total length of the variableLengthload embedded into the MIHF frame and isthe sum of MIHF variable header length andMIHF payload length. MIHF fixed headerlength is NOT included.
As currently specified in IEEE 802.21, the MIHF variable header 215 contains additional identifiers that help to analyze and coordinate the payload that is embedded. These identifiers are also represented in TLV format. Some possible values for the type field (of the TLV) of these identifiers specified in IEEE 802.21 include transaction ID (to match requests and responses), MIH Function ID/Session ID (to identify the communication peers), and synchronization information (to identify the timestamp of the received message).
The MIHF payload field 220 contains service specific TLVs that act as the payload of a message. Comparing the MIHF fixed header 205 in FIG. 2 (MIHF frame format) and the description of its fields in Table 1 (MIHF fixed header description), it should be noted that the “number of additional header identifiers” field that is shown in Table 1 does not exist in the MIHF frame 200 of FIG. 2.
The variable load length field 225 of the MIHF fixed header 205 is represented by 16 bits. The variable load length field 225 (as specified in IEEE 802.21) indicates that the total length of the variable load embedded into the MIHF frame 200 and is the sum of the length of the MIHF variable header 215 and the length of the MIHF payload 220. The length of the MIHF fixed header 205 is not included.
The variable load length field 225 is not necessary because the length of the MIHF variable header 210 can be calculated and the 16 bits used for its representation should be economized.
The MIHF fixed header 205 defines an acknowledgement request (ACK-req) field 230 to request an acknowledgment, and an acknowledgement response (ACK-rsp) field 235 to acknowledge receipt of a message. As specified in IEEE 802.21, acknowledgement messages are either attached (“piggy-backed”) or sent alone in a response packet. However, the IEEE 802.21 standard does not specify how to indicate that a response frame has no payload and serves as acknowledgement only. Thus, if a peer receives a message with the ACK-rsp bit set to ‘1’, it would have to check if there is payload or not. This is not efficient because if there is no payload, the MIHF variable load field 210 would contain dummy bits that might be interpreted as valid bits by the receiver. Thus, it is necessary to have a field that identifies pure acknowledgement messages and the MIHF frame 200 should have no MIHF variable load field 210. Currently there is no such field defined.
The IEEE 802.21 standard defines three MIHF protocol identifiers including an MIHF ID, a session ID and a transaction ID 240. The MIHF ID identifies the sender from where the MIHF frame 200 originated. The session ID is a unique identifier generated by the originator of a session. The transaction ID 240 is used for matching requests and responses, as well as matching request, response and indication to an ACK (see Table 1 above).
Thus, all of the three MIHF protocol identifiers (together) uniquely identify an MIHF frame (or message). However, only the transaction ID 240 is shown in the MIHF fixed header 205 whereas the MIHF ID, the session ID, and transaction ID 240 are supposed to be represented in TLV format and are specified to reside in the MIHF variable header 215 (which is part of the MIHF variable load 210). The problem is that using a TLV to represent each of the MIHF ID and the session ID will waste bits and complicate the decoding of the MIHF frame 200. In addition, the transaction ID 240 has already been granted a fixed field in the MIHF fixed header 205 and there is no need to re-represent it in TLV format in the MIHF variable header 215.